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A METHOD AND SYSTEM FOR MODELING AND 
AUTOMATICALLY GENERATING AN ELECTRONIC DESIGN 
FROM A SYSTEM-LEVEL ENVIRONMENT 

FIELD OF THE INVENTION 

[0001] The present invention generally relates to 
electronic circuit design tools, and more particularly to a 
tool that supports system-level development and simulation of 
a design that is bit-true and cycle-true to a hardware 
implementation. 

BACKGROTHSTD 

[0002] Modern electronic systems that are implemented in 
application-specific integrated circuits (ASICs), field- 
programmable integrated circuits (FPGAs), or complex 
prograitmiable logic devices (CPLDs) are often extremely 
complex, requiring years of effort to realize. For this 
reason, it is common to decompose the design problem into 
phases: a specification phase in which the functional 
requirements of the system are defined, a modeling phase in 
which an executable version of the functional description is 
realized, and an implementation phase in which a hardware 
realization of the system is created. For the end result to 
be correct, each phase must faithfully implement the result 
of the previous phase. For example, the hardware realization 
must exactly mirror the functional model created during the 
modeling phase. In practice, validating that implementations 
are faithful, which is the greatest part the design effort, 
often exposes design flaws or faulty assumptions upstream. 
This, in turn, results in reworking the earlier design 
representation. 

[0003] The modeling phase consists of capturing the design 
in an executable form, simulating, then analyzing the 
results. The modeling phase is appropriate for algorithm 
exploration, in which system parameters such as sample rates, 
data precision, and choice of functional blocks are decided. 
This process is iterative, with the results of analysis 
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leading to revisions that allow system specifications to be 
met. In the modeling phase, a high level of abstraction is 
desirable in order to facilitate algorithm exploration. For 
example, it is common to represent arithmetic values using 
floating point or fixed point rather than as buses of logic 
signals. Sampled data systems are also most conveniently 
modeled by defining sample rates rather than using explicit 
interconnections ("wires") representing clock and associated 
control signals (e.g., enable, reset). 

[0004] The hardware realization phase consists of creating 
a low- level implementation of the system in terms of 
primitives in an appropriate technology library. Hardware 
description languages such as VHDL and Verilog are commonly 
used for such a representation. In this representation, high 
level constructs such as sample rates and arithmetic values 
must be implemented in terms of clock signals and buses of 
logic vectors, and functional operators (e.g., discrete 
Fourier transform) must be mapped into appropriate circuitry. 
To achieve high performance, libraries of intellectual 
property (IP) blocks are commonly used. Such IP blocks are 
typically custom built to be efficient in the target 
technology. 

[0005] In traditional system design flows, the system 
designer is responsible for creating both the system model 
and the hardware realization. Moreover, the designer must 
ensure that the hardware realization meets the system 
specification. This validation can be extremely time- 
consuming, especially if redesign of the system model is 
required. 

[0006] For high-level modeling of digital signal 
processing (DSP) systems, a visual data flow paradigm has 
been found to be well suited and widely adopted by system 
architects. In a data flow model, the system is a network of 
functional operators that process data carried by signals 
between the operators. Since many DSP algorithms are 
naturally specified by signal flow graphs, the topology of a 
visual data flow model often closely resembles the algorithm 

2 



X 953 US PATENT 

specification. Specifying a system in a visual data flow 
environment is in some ways similar to specifying a design in 
a traditional schematic capture tool. Visual data flow 
environments provide a block editor, which can be used to 
construct models by connecting elements selected from 
libraries of functional blocks. In contrast to schematic 
tools, however, the library blocks and the simulation 
environment in a data flow tool provide a high level of 
functional abstraction, with polymorphic data types and 
operators to model arithmetic operations on integer, fixed- 
point, and floating-point data. Time evolution is typically 
specified by sample rates rather than by wiring explicit 
clocks . 

[0007] Although previous design flow environments support 
system-level modeling, the costs associated with the high 
level of abstraction include inefficient hardware 
implementations and inexact modeling of the hardware in the 
system-level simulation. Prior existing visual data flow 
environments have been suitable for system modeling (i.e., 
specification and simulation) , but have not provided 
automatic generation of a hardware realization of the system 
model. Instead, a typical design flow involves a manual 
translation of the system model to a hardware realization 
(e.g., ASIC or FPGA) , and a manual verification that ensures 
the hardware faithfully implements the system model. 
[0008] For example, the commercial visual data flow 
environment, SPW, from Cadence, provides simulation libraries 
and target implementations. However, the user is required to 
manually create the hardware implementation by explicitly 
replacing simulation models by the target library elements. 
This process is non- trivial, since replacement can involve 
one-to-many mapping (architectural synthesis, including re- 
timing and hardware sharing) , as well as synthesis of 
additional circuitry for inferred control logic (handshaking 
and clocking) . 
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[0009] A method and system that supports both modeling and 
automatic generation of a faithful and efficient hardware 
realization are therefore desirable. 

SUMMARY OF THE INVENTION 

[0010] In various embodiments, the present invention 
provides a method and system for creating an electronic 
circuit design from a system-level environment. A plurality 
of user-selectable system-level design objects are provided 
in the system-level environment. Each system-level design 
object is defined by a system-level function and is 
selectable by a system-level designer. A plurality of 
hardware- level design objects are also provided. Each 
hardware-level design object is configured to generate a 
hardware definition of a hardware- level function. Each 
system-level design object maps to one or more hardware- level 
design objects. In response to selections made by the 
designer, a system-level design is instantiated in a system- 
level design file. The system-level design includes user- 
selected ones of the system-level design objects. The system 
simulates behavior of the system-level design consistent with 
both the system-level functions and behavior of a hardware 
definition from the hardware- level design objects that 
implement the user-selected ones of the system-level design 
objects. Thus, the simulation at the system level is 
faithful to the system level functions as well as to the 
eventual hardware implementation. 

[0011] It will be appreciated that various other 
embodiments are set forth in the Detailed Description and 
Claims which follow. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0012] Various aspects and advantages of the invention 
will become apparent upon review of the following detailed 
description and upon reference to the drawings in which: 
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[0013] FIGS. lA and IB illustrate the difference between 
an example fast Fourier transform (FFT) operator in a system 
library and a FFT operator in a target hardware library; 
[0014] FIG. 2 is a functional block diagram of a design 
system structured in accordance with one embodiment of the 
invention; 

[0015] FIG. 3A is a block diagram of an example system- 
level design of an electronic circuit, and FIG. 3B is a block 
diagram of a hardware implementation generated from the 
system- level design. 

DETAILED DESGBTPTTON 

[0016] The present invention is described in terms of 
system-level designs for digital signal processing (DSP) 
systems and implementations for FPGAs . It will be 
appreciated, however, that the various concepts described 
herein, along with the various embodiments of the invention, 
can be applied to designs other than DSP systems and to 
implementation technologies other than FPGAs. The invention 
is applicable both to visual data flow modeling environments, 
and to other high-level design flows, e.g., based on a 
programming language such as C++, 

[0017] The present invention addresses the validation 
problem by providing a mechanism for automatically generating 
a hardware realization from a system model, thereby removing 
the necessity of verifying the ecjuivalence of the two 
representations. In addition, a mechanism and methodology 
are provided for the automatic production of a verified 
hardware representation from a high-level system model. In 
various embodiments, the invention includes a system library, 
a target library, and a compiler. The system library 
includes the functional operators in the system environment. 
The target library includes the implementations of the 
functional operators in the target hardware technology. The 
compiler translates a specified sequence of system library 
operations into a functionally corresponding circuit of 
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interconnected components in the target library. The mapping 
of functional operations to implementation components may be 
one-to-one, one-to-many, or many-to-one. 

[0018] The system library provides polymorphic arithmetic 
for floating-point, fixed-point, and integer operations. For 
quantization of data, the library supports various forms of 
saturation arithmetic and rounding. In each case, the target 
library provides equivalent data representations, although in 
hardware the values are represented as buses of standard 
logic vectors, with, for example, the binary point of a fixed 
point data representation being carried as an attribute 
(e.g., using VHDL generics). In the target library, floating 
point values may be realized by representing mantissas and 
exponents individually as buses of logic vectors. Functional 
operators are implemented as hardware design (sometimes 
referred to as "intellectual property") blocks that have been 
tailored for high efficiency. 

[0019] In addition to arithmetic abstraction that is 
mirrored in the target library, the system library elements 
implement handshaking protocols that allow data to flow 
through the system model without having explicit operators to 
control data transmission. In the target library, this 
functionality is, for example, realized through hardware in 
the blocks themselves and also through the injection of 
additional circuitry by the compiler. 

[0020] With the present invention, it will be appreciated 
that in simulation, the behavior of the system library 
matches that of the target library bit-for-bit and cycle-for- 
cycle. This means detailed hardware behavior is made 
manifest in the system model without needing to simulate the 
hardware realization itself. The mapping from system element 
to target element may be one- to-many, but for any 
parameterization in the system model, the bit and cycle 
behavior is an accurate representation of the corresponding 
hardware behavior at the sample rate defined in the system 
model. In the example embodiment, the designer is provided 
with the ability to specify in the system model the points at 
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which and in what fashion the hardware and system behaviors 
should be constrained to match, up to and including the 
ability of the user to relax the constraint on bit-true and 
cycle- true correspondence. With the relaxation of 
constraints, it is often possible for the compiler to realize 
more efficient hardware (e.g., through extensive re-timing 
and pipelining in the event that the user requests that the 
data match identically, but that the latency in its 
production can be tailored for performance) . 
[0021] The compiler allows networks of system library 
elements to be intermingled with networks of non-system 
library operators (e.g., user-defined elements) . The 
compiler resolves system-level parameters into attributes on 
the target library blocks, and into additional circuitry 
(ports, blocks, and signals) in hardware. For example, the 
compiler converts a sample-rate-based representation into a 
clocked hardware implementation, automatically inferring 
clock, clock enable, and clear ports and signals (not present 
in the system model) based on sample rates defined in the 
system model. In the event that an HDL simulation is 
desired, the compiler generates a test bench and test vectors 
in the system environment integrated with the generated 
hardware realization. 

[0022] The compiler also includes customization mechanisms 
to tailor the hardware realization to user specifications. 
For example, the compiler performs architectural synthesis, 
in response to user controls, when mapping system blocks to 
target blocks . 

[0023] The current invention provides the IP library 
embedded in the target library. The replacement of elements 
in the simulation model with target library elements is 
automatic. In one embodiment, the system library includes 
functions (S-f unctions) in the Simulink™ simulation 
environment from The MathWorks, Inc. The target library 
includes VHDL modules and support packages, and the compiler 
translates a Simulink™ model (the system model) into a 
hardware realization. The compiler operates on the system 
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model in successive stages. The software components of one 
embodiment of the invention are written in multiple 
languages, each selected for accomplishing the task at hand. 
The system library elements are written in a combination of 
MATLAB code (part of the Simulink™ environment), which 
interfaces directly to the underlying system simulation 
engine, and C++, which provides the benefits of object- 
oriented design. The compilation and simulation mechanisms 
chosen in this embodiment of the invention enable simulation- 
time customization of many system parameters (e.g., data 
precision) . Such customization is not provided in previous 
approaches such as SPW or a|RT. 

[0024] Functional operators in the system library are 
abstract to support ease of use. Operators in the target 
library are lower level, and often are highly detailed and 
closely tied to hardware. This makes the operators in the 
target library relatively complex to use. The simplicity of 
the system library operators makes algorithm exploration and 
high-level modeling practical. FiGs. lA and IB illustrate 
the difference between the fast Fourier transform (FFT) 
operator 52 in the system library and FFT operator 54 in the 
target library, it is clear that much of the detail in the 
hardware has been abstracted away in the system view, making 
the block much easier to use in practice. One of the tasks 
of the compiler is to bridge the gap between the system and 
hardware realizations of library elements. 

[0025] FIG, 2 is a functional block diagram of a design 
system structured in accordance with one embodiment of the 
invention. System 100 includes the system library (block 
112) and blocks that perform the phases of compilation. The 
compiler phases include resolving system parameters into 
attributes in an internal representation (block 122) ; 
expanding data types and inferring clock ports, signals, and 
generators (block 125); performing architectural synthesis 
(block 130); and netlisting into an HDL representation (block 
144). The target library (block 118) provides synthesizable 
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circuitry that wraps IP blocks (block 116) to extend the 
functionality, e.g., support of fixed-point data. 
[0026] System 100 illustrates how a Simulink™ system model 
is transformed by a MATLAB function (netlister) into an 
internal representation. This internal representation 
undergoes several transformations that resolve system 
parameters into the required control circuitry and target 
library mapping. In particular, data types are resolved into 
hardware-realizable forms, and clock signals, flip-flop clock 
enables and resets are inferred from system sample rates. 
[0027] A user's design 108 is defined within a system- 
level simulation environment 110, such as Simulink™. Based 
on the user's design, the system-level simulator calls on 
simulation functions 112, along with user simulation 
functions 114 to simulate the system-level design. The 
simulation functions 112 and user simulation functions 114 
are configured to be bit-true and cycle-true relative to a 
hardware implementation. Thus, the bit-true and cycle-true 
characteristics of the simulation functions 112 and 114 are 
reflected in the cores 116 and in the synthesizable VHDL 118, 
respectively. Simulation functions 112 are associated with 
system-provided design objects, and user simulation functions 
114 are those provided by the user for simulating user- 
provided design objects. 

[0028] In order to support simulation at the system level 
that is bit-true to a hardware implementation, each 
simulation function 112 is defined to operate on a particular 
data type. For example, one instance of an FFT simulation 
function is defined to operate on fixed-point sample data. 
The simulation of the system-level design is also cycle-true 
to the hardware implementation. The sample periods 
associated with the system-level design blocks are translated 
into clock enable signals in the hardware implementation. 
[0029] In translating the system-level design 108 to a 
hardware implementation, netlister 122 converts the system- 
level design into an internal representation, for example, 
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textual representation 124, of the design hierarchy. Also 
included in the textual representation are attributes of the 
design objects. For example, the text describing a 
multiplier block includes attributes that specify the 
precision, whether the multiplier is implemented using a 
serial or parallel algorithm, whether pipelining is required, 
and the size. The textual representation of the system-level 
design elements is shown as blocks 124. 

[0030] The hardware expander 126 further processes the 
textual representation of the design by adding control 
circuitry, signals, and ports for clock, clock-enable, and 
reset signals, and generating definition files 128 in the 
process. In addition, the hardware expander resolves data 
types. The additional ports that are required for a design 
are created by the hardware expander. For example, the 
hardware expander generates clock and clock-enable ports. To 
resolve data types, the hardware expander identifies types 
that have no direct analog in hardware (e.g., fixed point) 
and generates a suitable hardware representation. 
[0031] Ports for clock, clock enable, and reset signals 
are identified as follows. In the system-level design 108 
there are no explicit clocks. However, each object in the 
design outputs results at a sample rate that depends on the 
function of the object and on the sample rates of input data 
to the object. Hardware expander 126 performs the following 
operations in annotating the design with clock, clock-enable, 
and reset ports. 

[0032] First, the hardware expander determines the sample 
rates that have been specified for every port on every object 
and then calculates the GCD (greatest common divisor) of 
these values. A period p = g/r is assigned to each port, 
where r is the port ^ s sample rate and g is the GCD. Each 
period is a positive integer, and there is at least one port 
whose period equals 1. 

[0033] Second, the hardware expander determines which 
clock signals are needed for the netlist by looking at the 
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number of distinct periods assigned to ports. For example, 
if the set of periods assigned to ports is {1, 2, 3}, then 
the netlist must contain three clock signals with periods of 
1, 2, and 3. There is always a clock that runs with period 
1, which is referred to as the system clock. In hardware, 
every clock is derived from the system clock. 
[0034] Third, the hardware expander determines which of 
the clock signals to assign to each of the design objects by 
looking at the periods associated with the object's ports. 
If, for example, an object has ports with periods 1 and 2, 
then clock, reset, and clock-enable signals corresponding to 
periods 1 and 2 must be attached to the object. The wiring 
pattern is inferred from the distribution of sample periods 
amongst the ports. No clocks are assigned to combinatorial 
logic objects. 

[0035] Finally, the hardware expander adds one or more 
clock-generating components to the design; adds clock, reset, 
and clock-enable ports to the intermediate levels of the 
hierarchy; adds clock, reset, and clock-enable nets to each 
level; and then connects the clock generator, the newly added 
ports, and nets. 

[0036] For resolving data types, the hardware expander 
identifies system data types, for example, fixed-point and 
floating-point data types, that have no direct correspondence 
in hardware and generates suitable hardware to accommodate 
the specified data types. 

[0037] Architectural synthesis block 130 inputs the 
annotated design objects 128 and identifies specific logic 
cores 116 that are to be used by core generator 132 in 
generating VHDL files 134 for hardware simulation. 
Architectural synthesis block 13 0 also identifies additional 
supporting hardware that may be needed by a system- level 
design object. Thus, all the "leaf nodes" of the design are 
identified by architectural synthesis block 130. For 
example, an FFT object may require memory banks along with 
the logic that implements the function. The architectural 
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synthesis block outputs coimnands 140 that are input to core 
generator 132, which generates VHDL for the identified leaf 
nodes of the design. 

[0038] Architectural synthesis block 130 also generates 
descriptions of the connectivity between the leaf nodes of 
the design. The leaf nodes of the design and the defined 
interconnectivity descriptions are stored as files 142. 
[0039] After architectural synthesis, all of the design 
hierarchy and mapping to target library elements are known. 
To facilitate a high-performance implementation, a constraint 
file (not shown) is generated to provide constraints for the 
subsequent synthesis, technology mapping, placement and 
routing phases of an implementation. One important 
constraint is to specify a timing budget that should be met 
when implementing critical paths in the design. In the 
synchronous scheme described above, every flip-flop runs at a 
single rate, which must be fast enough to meet the overall 
performance requirements. However, in a multi-rate design, 
not every path needs to run at this rate, since flip-flop 
activity occurs only under the control of the clock enable 
signal driving the flip-flop. A multi-cycle path constraint 
is therefore created for every path that corresponds to logic 
running at a slower rate. 

[0040] VHDL netlister 144 creates wrapper VHDL files 146 
that provide the structural definition and interconnectivity 
of the hardware design. VHDL files 146 also define the 
testbench for hardware simulation. 

[0041] Testbench generation can be requested by a user at 
the time the user initiates generation of the hardware 
implementation with the netlister 122. To generate a 
hardware simulation testbench, the system-level simulation is 
translated into a VHDL file 146. At the system simulation 
level, simulation data are generated by ''source functions" 
that are provided with the simulator and that are 
parameter izable by the user. For example, one source 
function might be a sine wave generator, which supplies a 
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stream of values conforming to a sine wave, and an associated 
parameter is the frequency of the sine wave. While the 
system-level simulator 110 is running, the input values to 
the source functions are stored in a data file. The system- 
level simulation data files are then used to create hardware 
testbench data files and VHDL for inputting the data. 
[0042] In one implementation, cores 116 are executable 
programs that are called on by core generator 132 to generate 
VHDL files 134 for use by HDL simulator 150 and to generate 
hardware-specific, low-level design files 152. An embodiment 
of a core generator is provided in the CoreGen software from 
Xilinx. 

[0043] HDL simulator 150 performs hardware- level 
simulation on the hardware- level design as set forth in the 
VHDL files 134 and user-supplied VHDL files 118, with 
testbench data provided by VHDL files 146. HDL synthesis 
block 160 and foundry block 162 represent functional 
components in a conventional HDL design flow. 
[0044] System 100 supports integration of user-provided, 
system-level design objects with vendor-provided design 
objects in a system-level design 108. Where the user has 
provided synthesizable VHDL files 118 that implement user- 
defined system-level objects, the bit- true and cycle- true 
simulation of the system-level design that includes the user- 
provided objects can be performed. The user-provided objects 
are tagged as ^^black boxes" in the system-level design, and 
are not subject to the core generator implementation 
operations that are performed for the system-provided 
objects . 

[0045] FIG. 3A is a block diagram of an example system- 
level design of an electronic circuit, and FIG, 3B is a block 
diagram of a hardware implementation generated from the 
system-level design. System 200 is a multi-rate filter 
arrangement and includes input register 202, up-sampler 2 04, 
FIR filter 206, down-sampler 208, and output register 210. 
Input sample values are up-sampled by a factor of two, 
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filtered, and then down-sampled by a factor of three. The 
overall sample rate conversion for system 200 is 2/3. 
[0046] The sample rates that are specified at the system 
level are 48 kHz for input to register 202, 96 kHz for output 
from up-sampler 2 04 and input to FIR filter 206, and 9 6 kHz 
for output from down-sampler 208 and input to register 210. 
The normalized periods are determined to be 2, 1, and 3, 
respectively, as determined by the hardware expander 126, for 
example . 

[0047] Gateway design objects 240 and 242 define the input 
and output boundaries of system 200, respectively. Gateway- 
in objects are design objects used for an input interface, 
and gateway-out objects are design objects used for an output 
interface. The simulation function associated with the 
gateway-in object captures input simulation data, and the 
simulation function associated with the gateway-out object 
captures output simulation data. 

[0048] FIG. 3B illustrates a hardware implementation 250 
of the system-level design shown in FIG. 2A. Register 252 
corresponds to system object 202, block 254 correspond to 
system up-sampler 2 04, block 256 corresponds to system FIR 
filter 2 06, block 258 corresponds to system down-sampler 208, 
and register 260 corresponds to system object 210. The 
example illustrates the generation of clock-enable ports and 
clock control circuitry in the hardware design based on the 
information in the system-level design. 

[0049] Hardware component 270 is a control circuit that 
generates clock-enable signals to accommodate the sample 
periods of 1, 2, and 3. The system clock signal is input at 
the CLK port, and the system clock-enable signal is input at 
the CE port. The system clock-enable signal is also 
connected to the CE port of filter component 256 to implement 
the sample period of 1. The clock-enable signal at output 
port CE2 of component 270 is connected to the CE2 input ports 
of input register 252 and up-sampler 254 to implement the 
sample period of 2. The clock-enable-signal at output port 
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CE3 is connected to the CE3 input ports of down-sampler 2 58 
and register 260 to implement the sample period of 3. 
[0050] Even though it is not shown, it will be appreciated 
that some of the system-level objects may be implemented in 
the hardware-level design with multiple hardware components. 
For example, FIR filter 206 in the system design includes one 
or more memory modules that are used in conjunction with 
adders and multipliers, 

[0051] Having described the gateway-in and gateway-out 
design objects, further details regarding system-level 
simulation, testbench creation, and hardware- level simulation 
are set forth in the following paragraphs. During system- 
level simulation, data samples flow into the gateway-in 
objects and out of the gateway-out objects at regular sample 
periods. The input values are the stimuli, and the output 
values are the responses. The input samples that are 
captured during system-level simulation can be used for the 
hardware- level simulation. The faithfulness of the hardware 
representation can be demonstrated in that if the stimuli in 
the hardware-level simulation are the same as the stimuli in 
the system-level simulation, the responses from the hardware- 
level simulation will be the same as the responses from the 
system-level simulation. The values presented at the input 
ports in the hardware- level simulation and produced at the 
output ports are bit vectors, which represent the fixed-point 
values from the system-level simulation. 

[0052] The gateway-in objects in the system-level design 
are translated into VHDL components by the core generator 132 
and cores 116. The VHDL components for the gateway-in 
objects read the input data that was captured during system- 
level simulation and input the data to the hardware- level 
design components, for example to register 252 of FIG. 3B. 
Gateway-out objects are translated into VHDL components that 
compare hardware- level simulation results, for example, from 
register 260, to expected results, as captured during system- 
level simulation. 
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[0053] The fixed-point data type of the system-level 
generator 110 (e.g., Simulink) is represented using a 
std_logic_vector in VHDL. The position of the binary point, 
size of the container, and treatment of sign are supplied to 
the VHDL as generic parameters. To ease interpretation of 
fixed-point types in VHDL, the gateway objects convert the 
std_logic_vector into a VHDL real number by using the generic 
parameter information. A sequence of real numbers can be 
viewed as an analog waveform in an HDL simulator such as 
ModelSim from Mode Technology, Inc. This allows the user to 
view results in the same format as with the system-level 
simulator. 
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